개요

쿠버 RBAC을 하다가 문득 궁금점이 생겼다.
리소스를 지정할 때는 와일드카드(*)를 사용하는 것이 가능한데, 그럼 주체를 지정할 때도 이런 방식이 가능할까?
가장 궁금한 건 서비스 어카운트에 권한을 줄 때에 대한 부분이다.
가령 여러 네임스페이스에 tester라는 서계가 있다고 쳐보자.
모든 tester에 대해 특정 권한을 한번에 주는 방법이 있을까?

세팅

Vagrant로 Kubernetes v1.32 - Penelope를 구축해서 실험을 진행한다.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tester
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: sa-pod-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sa-pod-rb
subjects:
- kind: User
  name: system:serviceaccount:*:tester
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: sa-pod-role
  apiGroup: rbac.authorization.k8s.io

세팅은 다음과 같이 진행했다.
tester라는 서비스 어카운트가 있고, 이 녀석에게 RBAC 설정을 한다.
이때 클롤바를 할 때 유저 리소스를 사용하는데 와일드카드를 집어넣었다.

검증

만들어지는 것은 문제가 없다.

k auth --as "system:serviceaccount:*:tester" can-i list pod

그냥 *를 문자처럼 사용하면 문제없이 동작한다고 나온다.

그러나 막상 실제 네임스페이스 이름을 적어서 하는 것은 불가능했다.
결국 유저나 그룹으로 들어가는 subjects 필드는 완벽하게 문자열로서만 인식이 될 뿐이란 것이다.

서비스 어카운트를 subjects 필드에 넣어본다면

- kind: ServiceAccount
  name: tester
  apiGroup: rbac.authorization.k8s.io

이번에는 그냥 서비스어카운트를 사용해본다.

실수한 것이, apiGroup을 넣으면 안 된다.
근데 네임스페이스를 뺀 것은 의도한 부분으로, 가령 모든 네임스페이스의 tester라는 서비스어카운트에게 권한을 부여할 수 있는가가 궁금했다.
근데 namespace 역시 필수적으로 요구되는 필드이기 때문에 이러한 방법은 결국 불가능하다는 것을 알 수 있다.

결론

불가능이다.
사실 서비스어카운트를 지정할 때 네임스페이스를 와일드카드로 지정한다는 전략이 불가능하다는 것은 다른 주체를 대상으로 생각해보면 쉽게 알 수 있다.
유저나 그룹을 지정할 때, 범용적으로 범위를 권한을 부여하고 싶은 경우에는 그냥 그룹으로 묶어서 권한을 주는 것이 상식적인 전략이다.
각 그룹에 각 네임스페이스 권한을 주고 싶다면 각각의 롤바인딩을 만드는 것이 일반적이다.

그러나 지금 내가 한 발상은 하나의 롤바를 써서 모든 네임스페이스에 대해 권한 설정이 적용되도록 하려는 것이었다.
이것은 애초에 쿠버 RBAC의 설계 방향과 맞지 않으며, 네임스페이스별 권한은 네임스페이스마다 롤바를 시키는 것이 적절하다.

그러나 한편으로 생각하기에, 모든 네임스페이스는 default 서비스 어카운트를 가진다.
이 default 서비스 어카운트에 각 네임스페이스의 특정 권한을 부여하는 건 충분히 사용케이스는 있을 수 있지 않은가?
새로운 네임스페이스를 만들 때마다 새롭게 롤바를 만드는 건 조금 불편한 방식이라고 생각이 든다.
이를 직접적으로 조작하려면 Admission Control을 활용할 수 있겠으나, 아무래도 더 좋은 설정 방법을 제공해줄 순 없을까 하는 바램이 있다.
(Kyverno를 활용하면 편하게 세팅이 가능하긴 하다.)

내 아이디어

가령, 현재는 클롤바에 롤을 넣으면 검증 에러가 발생한다.
그런데 클롤바에 롤을 넣는 방식으로 세팅을 하면 모든 네임스페이스에서 각 네임스페이스에서만 활용할 수 있는 권한이 적용되도록 하는 것은 어떨까?

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sa-pod-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sa-pod-rb
subjects:
- kind: ServiceAccount
  name: default
roleRef:
  kind: Role
  name: sa-pod-role
  apiGroup: rbac.authorization.k8s.io

이런 식으로 세팅이 가능하게 만드는 것이다.
롤 자체는 네임스페이스 종속적이므로, 사실 이런 방식은 상당한 위화감이 있다.
또한 서비스어카운트 주체의 경우에도 네임스페이스를 명시해야만 하기에 문제가 있다.

음.. 각 리소스의 목적과 의미를 명확하게 유지하면서도 이게 가능하게 할 방법이 잘 떠오르지 않는다.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sa-pod-role
clusterBinds: true
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

새로운 필드를 추가해서 이 방식을 적용하는 것을 명시하는 방식을 생각해보았는데, 혼란을 야기하지 않을까 하는 생각이다.

관련 문서

참고